The present invention relates to data networking and more particularly to path computation in certain types of situation.
MPLS (Multi-Protocol Label Switching) Traffic Engineering has been developed to meet data networking requirements such as guaranteed available bandwidth. MPLS Traffic Engineering exploits modern label switching techniques to build guaranteed bandwidth end-to-end tunnels through an IP/MPLS network of labels switched routers (LSRs). These tunnels are a type of label switched path (LSP) and thus are generally referred to as MPLS Traffic Engineering LSPs.
Establishment of an MPLS Traffic Engineering LSP from an LSP head-end to an LSP tail-end involves computation of a path through the network of LSRs. Optimally, the computed path is the “shortest” path, as measured in some metric, that satisfies all of the relevant constraints such as e.g., required bandwidth, affinities, etc. Path computation can either be performed by the head-end LSR or by some other entity operating as a path computation element (PCE). The head-end or PCE exploits its knowledge of network topology and resources available on each link to perform the path computation according to the LSP Traffic Engineering constraints. Various path computation methodologies are available including CSPF (constrained shortest path first).
Path computation for MPLS Traffic Engineering LSPs is a non-trivial problem given that such LSPs have bandwidth requirements among other constraints and the links of the network have limited bandwidth capacities and specific characteristics. When a head-end or PCE attempts to place a Traffic Engineering LSP, it takes into account the LSP's bandwidth requirements and other constraints and assures that those constraints are satisfied along the path (e.g., there is sufficient capacity along every link of the placed path). If the LSP is successfully placed its bandwidth requirements are subtracted from the capacity on all of the constituent links. However, in certain situations there is no placement that will satisfy the Traffic Engineering LSP's bandwidth requirements.
In many networks, path computation is accomplished in a distributed fashion. Although a path computation element may perform all path computations for a given Autonomous System or area, it may operate only at the request of LSP head-ends. Furthermore, path computation elements usually do not retain state information for previously placed paths. An undesirable bandwidth fragmentation condition can arise since the path computation elements are not free to perform a simultaneous recomputation of the LSP paths. When bandwidth is excessively fragmented, there may theoretically be sufficient resources to meet all requirements but the inability to coordinate allocations leads to fragmentation of resources such that some requirements cannot in fact be accommodated.
The bandwidth fragmentation problem can be readily understood with reference to a simple example. FIG. 1 depicts a multiple Autonomous System network scenario with three Autonomous Systems, AS1, AS2, and AS3. Each link among the nodes of these three Autonomous Systems has 10 Mbps of capacity. Now assume that ASBR1 operating as a path computation element places a 3 Mbps MPLS Traffic Engineering LSP from node 108 to node 104 by traversing ASBR1, ASBR4, node 112, ASBR7, and ASBR9. Some time after this placement, node 110 requests ASBR1 to place a 3 Mbps LSP from node 110 to node 116. ASBR1 places this LSP to traverse ASBR3, ASBR6, node 114, ASBR8, and ASBR10. After these two LSPs are placed, node 102 requests ASBR1 to place an 8 Mbps LSP from node 102 to node 104.
This will not be possible because the two 3 Mbps LSPs have taken up enough bandwidth on every conceivable route between node 102 and node 104 to block placement of the 8 Mbps LSP. Network resources in fact exist to support all three LSPs because the originally placed 3 Mbps LSP could be rerouted to include nodes 108, ASBR2, ASBR5, ASBR6, node 114, ASBR8, ASBR10, node 116, and node 104. If the original LSP were rerouted in this way, capacity would be freed to allow the 8 Mbps LSP to be placed from node 102 to node 104 through node 108, ASBR1, ASBR4, node 112, ASBR7, and ASBR9, and node 104. Using currently available techniques, path computation element ASBR1 is unable to bring this situation about.
One partial solution to bandwidth fragmentation is to assign priorities to Traffic Engineering LSPs such that a request to establish a higher priority LSP can cause a lower priority LSP to be preempted and torn down if necessary to free up bandwidth. The probability of a new Traffic Engineering LSP being blocked due to bandwidth fragmentation can be reduced by assigning higher priority to the Traffic Engineering LSPs having higher bandwidth. To avoid the disruption of an abrupt preemption, soft preemption techniques have been developed where the head end is given time to reroute the preempted LSP before it is torn down by an intermediate node. This is however not a complete solution since the feasible number of priority levels is limited and it is difficult to map Traffic Engineering LSP bandwidth requirements to priority levels. If this mapping is done statically it must be tailored to the distribution of MPLS Traffic Engineering bandwidth requirements and manually reconfigured when this distribution changes significantly. Performing the mapping automatically would be very complex.
Improved solutions to the problem of bandwidth fragmentation are needed.